Looking forward to when this gets merged

I decided to make this v2 given the changes that went into. An alpha is up on NuGet https://www.nuget.org/packages/ByteSize/2.0.0-alpha1

I observed the BinaryByteSize DecimalByteSize NonStandardByteSize thing and I think it is wrong. Let me explain.

Have you ever worked with the DateTime struct? It represents a point in time. And it supports many many string representations that can all be parsed and rendered. There is even a calendar thing that can display a point in time from any calendar. And there are not many structs to work with it; there is just one.

I suggest keeping only one struct that can do all the desired jobs.

• ToString() and ToStandardString() can be used to display a standard format
• ToWindowsString() can be used to display the unacceptable but long-loved format (find another name if you wish. I do blame MS for this)
• ToDecimalString() can be used to display the decimal format
• ...

There are already some methods like these. FromKibiBytes and FromKiloBytes can be great together in the same class.

If you want compatibility for those who refuse the standard, you can make a static switch that will change the behavior of ToString.

If you don't like having multiple methods to get the string representation, then you can add an enum parameter or a renderer class.

If you still don't like that, you can also create a new format that can be passed to the ToString method (like DateTime). Something like "KiB#3" for "7.012 KiB", "BK" for "7 KB"...

What do you think?

Here is how I tend to display sizes in HTML. Everyone can understand whatever the size is.

There is only one size (1179694). There are many way of displaying it. So there should be one struct and many display methods.

Am I wrong?

I agree with @sandrock.

Another comparison could be temperature. Temperature is a property of a substance. It can have a value, which is probably represented the most canonically as an average velocity of particles in that substance. But as we all know, the temperature also has many more common representations, i.e. Fahrenheit or Celsius.

The temperature in this context is file size (or "content-length", or, more precisely, "data size"). The base representation is the number of bytes, or just "bytes". Kilobytes, kibibytes, megabytes, mebibytes, etc. are all alternative representations.

It doesn't make much sense to have NonStandardByteSize and StandardByteSize because byte size is always the same, here, on Mars, or anywhere else. Representations, however, can vary.

I appreciate the feedback in this thread.

To give some context, I initially had a single struct to manage both decimal and binary values. I went down the route of using separate structs make it explicit what the value being represented. I also wanted to keep backwards compatibility and provide users a way to do it the "wrong" way which is what the NonStandardByteSize struct is for. But thinking through this some more and reading the feedback here, I'm not seeing much value in doing it that way.

Given that, I'm thinking of dropping support for the non standard representation and going with the only decimal (kilobyte) and binary (kibibyte) because this is the trend we're heading down based on the limited research I've done.

So to summarize, alpha 2 of this will look like this:

• Namespace reverted back to ByteSizeLib.
• ByteSize struct with all the necessary methods to required for binary and decimals (i.e. FromKibiByte and FromKiloByte).
• No support for representing a kilobyte as 1024 bytes.

Thanks again for taking the time to give your feedback. I'll get started on the changes above. In the meantime, let me know if you agree/disagree with the direction.

I just pushed alpha 2 to NuGet. https://www.nuget.org/packages/ByteSize/2.0.0-alpha2

I realized that I don't have a good API setup for the .ToString to output a binary value. That's something I'll take a look at next.

I'm thinking .ToBinaryString() or just make the useBinaryByte parameter available on .ToString().